Matching used and allowed radio access technology types

ABSTRACT

The present invention provides methods, an application node ( 104, 26, 300 ), a policy node ( 108, 24, 400 ), a system for service delivery control related to access technology types and in particular for service delivery control based on allowed access technology types. Based on radio access technology types as defined by an application node related to a service provider as communicated to the policy node over the inter node interface Rx ( 106 ), and an radio access technology type with which a mobile phone ( 102, 22 ) communicates on at the moment, a determination is made as to whether the radio access technology type with which the mobile phone communicate son is among the allowed radio access technology types or not. If it is not, the current access technology type may be updated such that there is a match between the allowed radio access technology type and the current radio access rate.

TECHNICAL FIELD

The present invention relates in general to service delivery control incommunications systems and in particular to service delivery controlbased on radio access technology types.

BACKGROUND

In 3GPP R7 a new solution for Policy and Charging Control (PCC) wasintroduced. The PCC architecture comprises the Policy and Charging RulesFunction (PCRF) and the PCEF (Policy and Charging Enforcement Function).

The PCC architecture provides a service delivery control mechanism ofthe service flows in the Gateway (GW)-nodes such as the Gateway GeneralPacket Radio Service Support Node (GGSN), or other Internet ProtocolConnectivity Area Network (IP-CAN) gateways, such as Packet Data Gateway(PDG). Policy related functions provided and/or handled by PCC includeQuality of Service (QoS) control, gating, session events and chargingcontrol.

The PCRF is able to apply different types of policies for differentusers and different services. This policy decision can be based on forinstance subscription information, current access, such as Radio AccessTechnology (RAT) type. The RAT type parameter indicates which radioaccess technology a specific user is using at the moment, when using forinstance the networks Universal mobile telecommunications systemTerrestrial Radio Access Network (UTRAN), Global system for mobilecommunication Enhanced data rates for global evolution Radio AccessNetwork (GERAN), Wireless Local Area network (WLAN), and Global AreaNetwork (GAN).

Content providers may put restrictions on which access technologycertain content can be streamed or delivered on. One service providermay for instance buy the rights to stream or deliver for example thesoccer world championship on WCDMA, whereas an other service providermay buy the right to stream or deliver it on WLAN.

Allowed access technology types for a specific service may be specifiedand provisioned as static policies in the PCRF.

However, this brings the drawback such as that new policies and rulesfor allowed access technology types must be provisioned in the PCRF assoon as a new service is launched or deployed. This may typically beperformed by a Operations and Maintenance interface towards the PCRF.

Locating the logic directly in the application server means that aspecific solution per service is provided. A more generic approach isdesired.

In addition, inconsistencies between the policies in the PCRF and rules,if any, in the GGSN may occur, which could lead to that a policy in thePCRF may block an access that was earlier permitted by a rule in theGGSN.

SUMMARY

An object of the present invention is to provide methods, an applicationnode, a policy node and a system for providing an improved servicedelivery control.

According to an aspect of the present invention, there is provided amethod for providing service delivery attribute data for control of aservice providable to a portable electronic communication device, saidmethod comprising the steps of:

-   -   receiving an activation related service request from the        portable electronic communication device,    -   determining at least one allowed radio access type over which        the requested service can be provided from an application node        for the portable electronic communication device, and    -   sending an attribute related message associated with the        requested service to a policy node, said message comprising the        at least one allowed radio access type, such that the request        can be processed by the policy node.

Said method for providing service delivery attribute data may furthercomprise receiving at least identity related information associated withthe portable electronic communication device, and wherein the step ofdetermining may be performed in dependence of the received at leastidentity related information associated with the portable electroniccommunication device.

Said method for providing service delivery attribute data may furthercomprise obtaining service provision information related to the serviceas requested, and wherein the step of determining may be performed independence of the obtained service provision information.

Said method for providing service delivery attribute data may furthercomprise receiving an activation related service request from acommunication network over which the portable electronic communicationdevice communicates.

Said method for providing service delivery attribute data may furthercomprise the step of receiving an attribute related message responseassociated with the requested service, from the policy node.

According to another aspect, there is provided an application node forproviding service delivery attribute data for control of a service for aportable electronic communication device, said application nodecomprising:

-   -   a receiving unit adapted to receive an activation related        service request from the portable electronic communication        device,    -   a determining unit adapted to determine at least one allowed        radio access technology type over which the requested service        can be provided for the portable electronic communication        device, and    -   a transceiving unit adapted to send an attribute related message        associated with the requested service to a policy node and to        receive an attribute related message response associated with        the requested service from the policy node.

This receiving unit of the application node may further be adapted toreceive at least identity related information associated with theportable electronic communication device, and wherein the determiningunit may be adapted to determine the at least one allowed radio accesstechnology type in dependence of the received at least identity relatedinformation associated with the portable electronic communicationdevice.

The application node may further be comprise an application interfacebeing adapted to obtain service provision information, and wherein thedetermining unit further may be adapted to determine the at least oneallowed radio access technology type in dependence of the obtainedservice provision information.

The transceiving unit of the application node may further be adapted tosend the attribute related message and to receive the attribute relatedmessage response over an inter node interface.

The inter node interface related to the application node may furthercomprise the reference point Rx.

According to a yet another aspect, there is provided a method ofprocessing service delivery control data for a service request from aportable electronic communication device communication over acommunications network, comprising the steps of:

-   -   receiving an attribute related message associated with the        requested service, from an application node, said request        comprising the at least one allowed radio access technology type        over which the requested service can be provided for the        portable electronic communication device,    -   obtaining information associated with the radio access        technology type over which the portable electronic communication        device is communicating,    -   performing a service delivery control involving the radio access        technology type with which the portable electronic communication        device is communicating over the communications network and the        at least one allowed radio access technology type over which the        service can be provided from the application node, and    -   sending an attribute related message response associated with        the requested service, to the application node to initiate        provision of the service to the portable electronic        communication device, in dependence of the performed service        delivery control, such that the delivery of the service is        controlled.

Said method of processing service delivery control data may furthercomprise performing a comparison of the radio access technology typewith which the portable electronic communication device is communicatingover the communications network, with the at least one allowed radioaccess technology type over which the service can be provided.

Said step of sending an attribute related, message, comprised in themethod of processing service delivery control data, may further comprisesending radio access technology accept information confirming that theradio access technology type with which the portable electroniccommunication device is communicating over the communications network iscomprised within the at least one allowed radio access technology typeover which the service can be provided.

Said step of sending an attribute related message, comprised in themethod of processing service delivery control data, may further comprisesending radio access technology reject information confirming that theradio access technology type with which the portable electroniccommunication device is communicating over the communications network isnot comprised within the at least one allowed radio access technologytype over which the service can be provided.

Said method of processing service delivery control data may furthercomprise identifying a radio access technology type over which theportable electronic communication device can communicate over thecommunications network, said radio access type being an allowed radioaccess technology type over which the requested service can be provided,and sending a request to the portable communication device to update theradio access technology type over which said portable communicationdevice is communicating, to said identified radio access technologytype, such that the portable electronic communication device can beprovided with the requested service over the identified allowed radioaccess technology type.

Said method of processing service delivery control data may furthercomprise sending the identified allowed radio access technology type tothe application node.

According to a yet further aspect, there is provided a policy nodeadapted to process service delivery control data for a service that isrequested by a portable electronic communication device thatcommunicates over a communications network, said policy node comprising:

-   -   a transceiving unit adapted to receive an attribute related        message associated with the requested service, comprising at        least one radio access technology type over which the service is        allowed to be provided to the portable electronic communication        device,    -   a storing unit adapted to receive information at least related        to the radio access technology type over which the portable        electronic communication device communicates over the        communications network, and    -   a processing unit adapted to perform a service delivery control        related to the radio access technology type over which the        portable electronic communication device communicates over the        communications network and the at least one allowed radio access        technology type over which the service can be provided,        wherein the transceiving unit further is adapted to provide an        attribute related message response associated with the requested        service, to initiate provision of the service to the portable        electronic communication device, in dependence of the performed        service delivery control.

The processing unit of the policy node may further be adapted to performa comparison of the radio access technology type over which the portableelectronic communication device communicates over the communicationsnetwork, with the at least one allowed radio access technology type overwhich the service can be provided.

The processing unit of the policy node may further be adapted toidentify the radio access technology type over which the portableelectronic communication device communicates over the communicationsnetwork as an allowed radio access technology type over which therequested service can be provided.

The processing unit of the policy node may further be adapted toidentify a radio access technology type over which the portableelectronic communication device can communicate over the communicationsnetwork, said radio access technology type being an allowed radio accesstechnology type over which the requested service can be provided, andadapted to send a request to the portable communication device to updatethe radio access technology type over which said portable communicationdevice communicates, to said identified allowed radio access technologytype, such that the portable communication device can be provided therequested service over the identified allowed radio access technologytype.

The transceiving unit of the policy node may further be adapted toreceive the attribute related message associated with the requestedservice, from the application node and to send the attribute relatedmessage response associated with the requested service to theapplication node, over an inter node interface.

The inter node interface related to the policy node may further comprisethe reference point Rx.

The policy node may further comprise a policy and charging rulesfunction.

According to a yet a another aspect, there is provided a method ofperforming service delivery control of a service provided to a portableelectronic communication device, said method comprising the steps of:

-   -   receiving an activation related service request from the        portable electronic communication device that communicates over        a communications network,    -   determining at least one allowed radio access technology type        over which the service can be provided to the portable        electronic communication device,    -   obtaining information associated with the radio access        technology type over which the portable electronic communication        device communicates over the communications network,    -   performing a service delivery control involving the radio access        technology type with which the portable electronic communication        device communicates over the communications network and the at        least one allowed radio access technology type over which the        service can be provided, and    -   sending an attribute related message response associated with        the requested service, to the application node to initiate        provision of the service provided, to the portable electronic        communication device, in dependence of the performed service        delivery control.

According to a yet a different aspect, there is provided a system forperforming service delivery control of a service as requested by aportable electronic communication device, said system comprising:

-   -   a receiving unit adapted to receive an activation related        service request from the portable electronic communication        device that communicates over a communications network,    -   an application node adapted to provide the service as requested        by the portable electronic communication device, and adapted to        determine at least one radio access technology type over which        the service is allowably provided,    -   a transceiving unit adapted to receive information at least        related to the radio access technology type over which the        portable electronic communication device communicates over the        communications network,    -   a policy node adapted to perform a service delivery control        related the radio access type with which the portable electronic        communication device communicates over the communications        network and at least one allowed radio access technology type        over which the service can be available, wherein the policy node        further is adapted to provide an attribute related message        response associated with the requested service to initiate        provision of the service to the portable electronic        communication device, in dependence of the performed service        delivery control, and    -   an interface between the application node and the policy node,        said interface being adapted to communicate an attribute related        message associated with the requested service from the        application node to the policy node and to communicate an        attribute related message response associated with the requested        service from the policy node to the application node.

The inter node interface of the system may further comprise thereference point Rx.

It should be emphasized that the term “comprises/comprising” when beingused in the specification is taken to specify the presence of the statedfeatures, integers, steps or components but does not preclude thepresence or addition of one or more other features, integers, steps orcomponents or groups thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to explain the invention and the advantages and featuresthereof in more detail, embodiments will be described below, referencesbeing made to the accompanying drawings, in which

FIG. 1 is a block diagram illustrating an embodiment of a system;

FIG. 2 is a block diagram illustrating an embodiment of signal exchange;

FIGS. 3 and 4 are block diagrams illustrating an embodiment of anapplication node and a policy node, respectively; and

FIGS. 5 and 6 are flowcharts illustrating embodiments of method steps.

DETAILED DESCRIPTION

By referring to FIG. 1 showing a block diagram illustrating anembodiment of a system, 100, a few features comprised in someembodiments of the present invention will be described.

Within said embodiment the system 100 in FIG. 1, comprises anapplication function (AF) 104. Within the embodiment of system 100, theAF may be realised by a streaming server. The AF is connected to apolicy node 108 in the form of a Policy and Charging Rules Function(PCRF) 108. The AF 104 may be connected to the PCRF 108 via an interfaceon which attribute related messages in the form of AuthenticationAuthorisation requests (AA-requests) and attribute related messageresponses in the form of Authentication Authorisation responses(AA-responses) can be communicated. According to some embodiments thisinterface 106 comprises the reference point Rx.

Moreover, within the embodiment as illustrated in FIG. 1, a userequipment (UE) such as a mobile phone 102 that is one example of aportable electronic communication device 102 is connected to the AF 104.It should be noted that the UE 102 is in fact connected to the AF viathe GGSN, but due to FIG. 1 being a schematic block diagram this is notexplicitly illustrated.

In addition, a Policy and Charging Enforcement Function (PCEF) of aGateway General Packet Radio Service Support Node (GGSN) 114 may beconnected to the PCRF 108 over a Gx interface as indicated in FIG. 1.

According to an alternative embodiment, the AF is realised by aProxy-Call Session Control Function (P-CSCF), being one part of anapplication node. The application node may further comprise aServing-CSCF (S-CSCF) and an Application Server (AS). Within thisembodiment it is the AS that can receive the SDP Offer and makedecisions concerning RAT types being allowed by the service provider.The AS may consequently send the SDP Answer directed to the UE.

Hereinbelow, some embodiments of the invention will mainly be describedin the context of the 3^(rd) Generation Partnership Project (3GPP) PCCarchitecture.

A basic concept of the embodiments of the present invention can bedefined such as that 1) the services of the service provider should beable to specify allowed access technology types during session setup atdeployment of a service, without having to make modifications in thePCRF, 2) the Rx interface between the AF and the PCRF is extended toinclude RAT types that are allowed by the AF, 3) the logic within thePCRF is extended so that it is capable to perform matching of allowedRAT types as received on Rx with the RAT type on which the UEcommunicates at the moment as may be received on Gx during IP CANestablishment and 4) the possible decisions that the PCRF can take areeither to send a simple Accept or Reject response to the service sessionsetup request, or possibly to trigger a mechanism with the aim to set upa new allowed RAT type based on a list of allowed RAT types.

Service Logic

As mentioned above the service logic, that is the AF104 may be realisedby an application server (AS) itself, for example a streaming server,according to some embodiments. Alternatively, the application function(AF) can be realised by a a Proxy-Call Session Control Function (P-CSCF)being one part of an application node, where said application nodefurther may comprise a Serving-Call Session Control Function (S-CSCF).

According to some embodiments there is session setup signalling, forexample Session Initiation Protocol (SIP), between the UE and the AF.This signalling may comprise the Session Description Protocol (SDP).

The service logic, for instance the AS comprising the AF specifies whichradio access technology type is allowed for a particular user andservice. This RAT type information is then communicated directly to thePolicy and Charging Rules Function (PCRF).

According to an alternative embodiment wherein the application nodecomprises the AF in the form of the P-CSCF, that is in the InternetProtocol Multimedia Subsystem (IMS) case, the radio access technologytypes which are allowed may be communicated via the P-CSCF to the PCRF.

The service should be able to specify the priority of the allowed RATtypes that are sent from the AF to the PCRF being one example of thepolicy control node. Such priority information may determine whether theinformation as sent by the AF to the PCRF shall override any staticallyprovisioned rules that might exist in the PCRF/Subscription ProfileRepository (SPR).

According to some alternative embodiments, the static rules of the PCRFare given higher priority than the information sent from the AF, or viceversa.

The embodiments may be operator-specific and enable one operator tochoose a first embodiment and another operator to choose a secondembodiment, wherein the first and second embodiments differ from eachother in this respect.

Application Function—Policy Control Interface

The information about allowed Radio Access Technology (RAT) types may becommunicated to the PCRF using extensions to the Rx interface, accordingto some embodiments.

Such extensions to the Rx interface could be introduced in the form ofnew Attribute Value Pair (AVP) that includes all allowed RAT types, thatcould then be communicated over the extended Rx interface.

A central point according to some embodiments is that RAT type relatedinformation is communicated over an interface that is positioned betweenthe application function, being one example of an application node, andthe policy node.

According to yet some alternative embodiments, information about allowedRAT type may be communicated between the application node and the policydecision node on an entirely new interface. One example of a newinterface may for instance be based on the Simple Object Access Protocol(SOAP). In this case the new interface would typically be used toprovide RAT types for the service specific policy. The policy decisionnode could also query the application node for allowed access technologytypes to avoid any static behaviour of a configured policy if present.

PCRF Logic

The PCRF will receive the current RAT type for a particular user duringInternet Protocol Connectivity Area Network (IP CAN) establishment thatoccurs when the UE attaches to the network. The current RAT type valueis stored in a database in the PCRF.

The PCRF will upon session setup, that is when it receives informationover Rx during session signalling, compare the current RAT type with thelist of allowed RAT types as received from the AF.

Statically provisioned RAT type rules may moreover also be provisionedin the PCRF/SPR.

According to some alternative embodiments, the current RAT type mayhence be compared with both the default RAT types statically provisionedin the SPR, which are activated at bearer (IP CAN) establishment and thelist of allowed RAT types to be used at establishment of a session.

The PCRF can request subscription related information related to theIP-CAN transport level policies from the SPR based on subscriber ID, aPacket/Public Data Network (PDN) identifier and possibly further IP-CANsession attributes.

This enables that the current RAT type can be updated to a RAT type thatis not among the allowed RAT types but that is instead staticallyprovisioned in the PCRF/SPR.

The PCRF will accordingly Accept the session setup request if thecurrent RAT type as received from the GGSN at IP CAN establishment isincluded in the list of allowed RAT types as received from the AF atsession setup, or statically provisioned in the PCRF/SPR. Prioritysettings for various different RAT type alternatives may also be takeninto account here.

Else, that is if the current RAT type is not included in the list orstatically provisioned in the PCRF/SPR, the PCRF will take the decisionto either Reject the session setup request, or to trigger theestablishment of one of the allowed RAT types, if this is possible oralternatively to trigger one of the RAT type that are staticallyprovisioned in the PCRF/SPR

Taking the decision to trigger the establishment of one of the allowedRAT types, will of course require that the UE is in range of any otheraccess networks than the one currently used. Which RAT type that thePCRF should trigger may be decided by the PCRF itself, that is thepolicies regarding access priorities may be provisioned in the PCRF, andthe list of allowed accesses as sent on the Rx interface sorted inpriority order, for instance 1) UTRAN 2) GERAN, 3) (WLAN), and 4) GAN.

The PCRF may initiate the terminal to change the RAT type.

An alternative to the above described triggering mechanism is to let theAF and the UE handle the RAT type change. A reject message that is sentto the AF may be propagated to the terminal. The terminal may then beable to change RAT type or inform the end user about the need to updatethe RAT type that is used at the moment.

In order to better explain the embodiments below, a presentation of thefigures will now follow.

The block diagram of FIG. 2 illustrates an embodiment of signal flowbetween the UE 22, the PCRF 24, and the AF 26.

FIG. 3 is a block diagram illustrating an embodiment of a simplifiedapplication function, being one example of an application node. Theapplication function, 300 according to this embodiment comprises a SDPPort, 302 connected to a determining unit 304 that is further connectedto an application interface 306. The determining unit 304 is alsoconnected to a transceiving unit 308. All functions and ports, that isthe SDP port 302, the determining unit 304, the application interface306, and the transceiving unit 308 may moreover also be connected to acontrol unit 310, which control unit 310 controls the steps as performedby said units, according to some embodiments.

Moreover within the embodiment of FIG. 3, said figure also comprises theUE 312 being connected to the SDP Port 302. In addition, thetransceiving unit 308 of the AF 300 is connected to the PCRF 314.

Similarly FIG. 4 is a block diagram illustrating an embodiment of a PCRFbeing one example of a policy node. The PCRF 400 according to thisembodiment comprises a transceiving unit 402 connected to a comparingunit 406. In addition there is provided a database 404 connected to thetransceiving unit 402 and to the comparing unit 406. A control unit 408may also be connected to the transceiving unit 402, the database 404,and the comparing unit 406, controlling the steps as performed by saidunits, according to some embodiments.

Below reference is made to FIGS. 5 and 6 that are flowchartsillustrating embodiments of method steps.

AF Steps And Features—A Football Game Scenario

In order to explain possible steps and features of the AF, and also ofthe PCRF below, a football game scenario is referred to in thefollowing.

When the user of a UE such as mobile phone wishes to gain access to acertain football game and activates the mobile phone accordingly forinstance by pressing a button in order to experience the football game,a message is sent from the UE to the AF.

According to some embodiments, such a message may comprise a SDP Offer,which means that the SDP Offer is received by the AF 104,26;300, andthat the SDP Offer is sent by the UE 102;22 being one example of aportable electronic communication device. This step of receiving an SDPOffer is illustrated by step 202 in FIG. 2, where this step is oneexample of receiving an activation related service request. In FIG. 3 itis illustrated that the UE 312 sends a message S-302 to the SDP Port 302of the AF 300. The message S-302 is thus the SDP Offer according to someembodiments. In addition, FIG. 5 also comprises step 502, Receiving SDPOffer from UE, being another example of the communicating the servicerequest from the UE to the AF

This SDP Offer message may thus be received by the SDP Port 302 of theAF 104,26,300, where said SDP Port is schematically illustrated in FIG.3.

The SDP Offer typically comprises information associated with theidentity of the user equipment, and information about the requestedservice, in the form of an Internet protocol multimedia subsystemCommunication Service Identifier (ICSI), which in this case correspondsto packet flows of the desired football game.

It should be noted that the information as comprised in the SDP Offermay not be received directly from the UE, but may be received from theGGSN via input from the current radio network.

In addition to receiving the SDP Offer by the AF in step 202,502, withsignal S-302 the method according to these embodiments also comprisesobtaining the identity of the UE in step 504 from the SDP Offer. Thisstep, step 504, being an example of receiving at least identity relatedinformation associated with the portable communication device mayaccording to some alternative embodiments be comprised in step 202,502,receiving SDP Offer by the AF from UE.

According to another alternative embodiment, identity relatedinformation may be received by the AF in the form of an IMS useridentity.

A SDP Answer message is subsequently sent from the AF to the UE, whichcorresponds to step 204; 506 according to these embodiments. Sendingsuch a SDP Answer by the AF may be performed by the SDP port 302, undercontrol of the control unit 310 of the AF, although it is not explicitlyillustrated At this step the AF thus acknowledges that the UE identityis requesting a service.

Within the method according to some embodiments, this step of obtainingservice provision information related to the requested servicecorresponds to the step of obtaining service information from the SDPOffer S-302, step 508. This step is typically performed by the SDP Port302 under the control of the control unit 310. At this step the AF mayobtain information about the requested service being the football game.

Having obtained the service information in step 508, obtaining RAT typedata for service in step 510 is followed. As we saw above, the serviceinformation may be received by the SDP port 302, from SDP Offer S-302.The RAT type data for service in step 510 may however be obtained fromthe application interface 306 of the AF 300, according to someembodiments.

The information that is received in step 510 may also comprise theindividual priorities of the RAT types, which typically can be definedby the service provider in the form of a streaming server.

Thus, the SDP Port 302 has received the identity of the UE and serviceinformation about the service as requested by the UE. Also theapplication interface 306 has obtained RAT type data for servicecomprising the RAT type on which the requested service may be providedfrom the AF.

Information on the identity of the UE and service information about theservice as requested is thus communicated to the determining unit 304 bythe message S-304. Also, the obtained RAT type data with the RAT typeson which the requested service may be provided, can be communicated tothe determining unit 304 by the message S-306.

Now, the determining unit 304 of the AF 300 may perform in step 512 thestep of determining the allowed RAT types for the service based on theidentity of the UE and the obtained service RAT type data, being oneexample of determining at least one allowed radio access technology typeon which the requested device can be provided from an application nodefor the portable electronic communication device.

In FIG. 2, step 512 of FIG. 5 is illustrated by step 206, determiningRAT types allowed by the AF.

According to a scenario of an embodiment, as illustrated in FIG. 1 asscenario I, the determining unit determines that the football game maybe provided to the UE, having the UE identity (ID) “A” and thusbelonging to a specific user, on the RAT types Y and X.

According to some embodiments the determining unit 304 may perform thisdetermination under control of the control unit 310.

The AF has thus determined which RAT types the football game can bedistributed on to the specific user. The so called service specific anduser specific allowed RAT types are thus determined.

It should be kept in mind that these RAT types, UTRAN and WLAN in thisexample, are the RAT types on which the football game can be provided bythe service provider. It is not determined on which RAT type(s) the UEcan receive the football game. This remains to be determined.

The next step of the method according to some embodiments is the step ofsending an attribute related message, as illustrated in FIG. 3 bymessage S-310, in the form of an authentication authorisation request(AAR) to the PCRF 24, step 208, 514, said step being one example ofsending an attribute related message associated with the requestedservice to a policy node, said request comprising the at least oneallowed radio access technology type, such that the request can beprocessed by the policy node.

This attribute related message may be generated by the transceiving unit308 after having received the information about the allowed RAT typesfrom the determining unit 304 with the message S-308, under control ofthe control unit 310, according to some embodiments.

In FIG. 2, as indicated above this is schematically illustrated by step208, receiving attribute related message by the PCRF 24 as sent by theAF 26, again according to some embodiments.

It may be noted that it is in fact the UE source and port IP address,being unique identifiers of the 5-tuple that is communicated over the Rxinterface, which unambiguously define the stream of the service request,according to some embodiments.

PCRF Steps and Features—Football Game Scenario

FIG. 6 that is a flowchart illustrating embodiments of method stepstypically to be performed by a policy node. These steps start withconnecting to the latest steps of the method steps in FIG. 5, that isstep 514.

The first step of FIG. 6 is thus the step of obtaining an attributerelated message S-402 from the AF over the reference point Rx, in theform of the AA-request in step 514.

Thus step 602 comprises obtaining the attribute related message S-402containing allowed RAT types from the AF. The interface between the AFand the PCRF may according to some embodiments comprise the referencepoint Rx.

However, and as mentioned above under Application function—Policycontrol interface, the interface between the application node and thepolicy node may be realised by a completely new interface.

Returning to the step of obtaining attribute related message containingallowed RAT types, where the attribute related message corresponds tothe AA-request, can be obtained by a transceiving unit 402, according tosome embodiments.

By receiving the attribute related message S-402 by the PCRF 24 from theAF 26, the PCRF 24 has received information that the requested servicecan be provided from the AF 26 with the UE 22 as destination UE 22 on atleast one RAT type taken the identity of the UE 22 and the subscriptionof the user into account. It is now the task of the PCRF 24 to gainknowledge of the RAT type on which the UE 22 currently communicates.

The PCRF 24 may then retrieve information about the RAT type on whichthe UE 22 at the moment communicates. This is performed in step 604,retrieving current RAT type. In the signal exchange of FIG. 1, this stepcorresponds to step 210.

The actual RAT type information is typically delivered to the PCRF24,400 already during IP CAN establishment via Gx-signalling from agateway such as a Gateway General packet radio service Support Node(GGSN) 412 with the message S-404. The information about the RAT typethat the UE communicates on is therefore typically retrieved by thePCRF, according to some embodiments.

Information on which RAT type the UE 22 communicates at the moment maybe e stored in a database 404 of the PCRF 400. In FIG. 1, the right handtable 112 schematically illustrates such content where the UE ID and thecurrent RAT type are stored. This stored information tells us that theUE with identity “A”, currently communicates on the RAT type X,following scenario I, when X within this example is WLAN.

Having retrieved the RAT type on which the UE communicates at the momentin step 604, this information is communicated from the database 404 tothe comparing unit 406 by the message S-406. Information on the allowedRAT types on which the service as requested by the UE may be provided bythe AF is also communicated from the transceiving unit 402 to thecomparing unit 406 by the message S-408.

Having access to the information from messages S-406 and S-408, the stepof comparing the current RAT type and the allowed RAT types, being anexample for the service delivery control step can now be performed bythe PCRF in step 606 and in step 212 of FIG. 2, under control of thecontrol unit 408.

Again with reference to scenario I and the left hand table 110 of FIG.1, it can be seen that the user having UE ID “A” may be provided withthe football game from the Internet Protocol Source (IPSRC) on the RATtype Y being UTRAN and X being WLAN. Moreover it can be seen that the UEcurrently communicates on RAT type X, that is WLAN.

Step 606 or step 212 is typically performed by the comparing unit 408 ofthe PCRF 400, which is connected to the transceiving unit 402, fromwhich the comparing unit 406 can obtain the at least one allowed RATtype S-408 on which the requested service can be provided by the AF. Theinformation S-406 on the RAT type that is used at the moment by the UEis received from the database 404.

Database 404 may thus be arranged to store the RAT type on which the UEcommunicates, as earlier mentioned and as illustrated by the right handtable 112 in FIG. 1.

Within the method steps of flow chart in FIG. 6 the following step isdetermining whether the current RAT type is among the allowed RAT typesas received over the Rx interface, in step 608.

This step may be performed by the comparing unit 408, provided withinformation S-406 from the database 406 and with information S-408 fromthe transceiving unit 402, under control of the control unit 408.

In FIG. 1, following scenario I, it is illustrated in the left handtable 110 the allowed RAT types on which the AF can provide the footballgame, having the IPSRC “1”. Also, from the right hand table 112, it isillustrated that the RAT type on which the UE ID equals “A”communicates, is X (WLAN), meaning that the RAT type X is found withinthe at least one RAT types, RAT type Y (UTRAN) and RAT type X (WLAN), onwhich the service may be provided. There is thus a RAT type match madeby the comparing unit 408 of the PCRF 400.

Having determined that there is a match by the comparing unit 406, amessage S-410 is sent to the transceiving unit 402 of the PCRF 400.

Answering the interrogation in step 608 in an affirmative manner,following scenario I in FIG. 1, defines the subsequent step of themethod of FIG. 6 to be sending an accept to the AF over the interfacebetween the PCRF and the AF, in step 610. According to some embodiments,this interface is the reference point Rx.

This step of sending an accept may be executed by the transceiving unit402 under control of the control unit 408, where the accept is oneexample of an attribute related message response S-412 sent from thetransceiving unit 402 to the AF 410. This attribute related message iscommunicated via the inter node interface or reference point Rx.

In FIG. 2, after having determined that there is a RAT type match, bythe comparing unit 406, as illustrated in step 212, the step of sendinga response is illustrated by step 214 comprising sending accept by thePCRF to the AF, wherein the accept is one example of an attributerelated message response that may be realised as a AA-response, againaccording to some embodiments.

In the case the football game can only be delivered on for instanceGERAN and UTRAN, and the mobile phone at the moment communicates onWLAN, we would have a different scenario, scenario II as illustrated inFIG. 1 by the left and right hand tables, 110 and 112, respectively.

Following this scenario II, the football game now delivered by IPSRC 2can only be delivered on RAT type Z being GERAN and RAT type Y beingUTRAN, whereas the current RAT type of the UE having the identity UE IDA is RAT type X that is WLAN. It is therefore determined in step 608that the current RAT type can not be found among the RAT types that areallowed by the AF, as determined by the comparing unit 406 under controlof the control unit 408. The answer to the interrogation in step 608 isthus negative, for which reason the following step of this method is todetermine whether to trigger one RAT type that is allowed and that isdifferent from the current RAT type, in step 612. This step may beperformed by the control unit 408.

According to alternative embodiments, static rules as provisioned in thePCRF may be taken into account. If it is determined that the current RATtype is not among the allowed RAT types in step 608, the PCRF mayaccording to this alternative embodiment determine whether the currentRAT type is statically provisioned in the PCRF or not.

This determination may be performed by the PCRF with the assistance ofthe Subscription Profile Repository (SPR) that is arranged to comprisestatic subscription rules.

If it is determined in the PCRF that the current RAT type indeed isstatically provisioned, for instance in the SPR, an accept message willbe sent to the AF according to step 610.

If it is determined by the PCRF that the current RAT type is notstatically provisioned, and that the current RAT type was found not tobe among the allowed RAT types in step 608, the method continues withthe step of triggering of one RAT type that is different from the RATtype on which the UE communicates at the moment, wherein the RAT type iseither allowed by the AF or statically provisioned by the PCRF/SPR inthe case static rules are provisioned, or both, step 612. This step maybe performed by the control unit 408 with assistance by the comparingunit 406 and the database 404.

According to some embodiments the step of determining whether to triggerone RAT type that is different from the current RAT type in step 612 ofFIG. 6, corresponds to step 216 of FIG. 2, determining whether to updatecurrent RAT type to one of allowed RAT types.

If the comparing unit 406 and control unit 408 determine not to triggera RAT type different from the current RAT type, that is answering theinterrogation in step 612 in a negative manner, the method of theseembodiments is proceeded by the step of sending a reject response overthe interface Rx to the AF 410 in step 614.

This reject response is typically one example of an attribute relatedmessage response S-412 sent from the transceiving unit 402 to the AF410. This attribute elated message response may be realised by anauthentication authorisation response (AAR).

Also, sending the attribute related message response as a reject ispreceded by a message S-410 sent from the comparing unit 406 to thetransceiving unit 402, comprising information not to trigger a RAT typedifferent from the current RAT type.

One reason not to trigger a RAT type that is different from the RAT typeon which the UE at the moment communicates, that is the current RAT typefor the UE, could be that the UE may not support any other RAT type thanthe one that is used at the moment.

Another reason not to trigger a RAT type that is different from the RATtype on which the UE at the moment communicates may be that otherservices are already making use of said current RAT.

If, however, the comparing unit 406 of the PCRF answers theinterrogation in step 612 in an affirmative way, the method may proceedby a step of obtaining RAT type priorities, in step 616. This step maycomprise obtaining the priorities of the allowed RAT types, and may alsocomprise obtaining the priorities of any statically provisioned RATtype, as stored in the SPR, according to an alternative embodiment.

For the reason that there may be several RAT types that are allowed bythe AF on which the service may be provided, different RAT types mayhave different priorities as defined by the AF. For instance it may bemore preferable to the service provider to provide the football game onWLAN instead of GERAN, just to mention one example.

Also, the geographical position may affect the available RAT types, forinstance WLAN may not be available on the countryside whereas it mayvery well be available in the city. Moreover, WLAN is typically presentat hot spots. The coverage by the network or networks, the time of theday, the load of the network(s), among others may also be parametersaffecting the priorities as defined by the service provider or network.For instance, one operator may have bought the right to deliver aservice on WLAN, but not during busy hours, as the right for using WLANduring that time, may have been bought by a different operator.

Having obtained RAT type priorities for both the allowed RAT types andpossibly also for the RAT types that are statically provisioned,according to an alternative embodiment, the next step of the method ofFIG. 6 is the step of obtaining internal UE RAT type preferences, step618. In this step preferences internal to the UE may thus be obtained,for instance that GERAN is preferred to WLAN for one or more reasons.

The preferences may also be based on whether the UE is in range of anyaccess networks other than the one that is being used at the moment.

The subsequent step may thus be the step of selecting a specific RATtype that is different from the current RAT type, respecting thepriorities of the provider and the preferences of the UE, step 620.

Within this step the priorities as provided by the AF may be ruling overthe preferences for the UE. If the AF can provide the requested service,in this case the football game on two equally prioritized allowed RATtypes, such as WLAN and GERAN, and the UE prefers one of said two RATtypes to the other, then this UE preferred RAT type is of courseselected.

If the AF can provide the requested service on two differentlyprioritized allowed RAT types, that is one being prioritized to theother, but the UE prefers the one having no or lower priority, the moreprioritized RAT type is selected, in case the priorities as defined bythe AF rule over the preferences of the UE.

If however the AF provides two RAT types for which one is prioritized tothe other, and the UE is unable to communicate on the RAT type beingprioritized, the RAT type having the lower priority shall be selected asthe new RAT type to communicate on.

There are further examples of priorities and preferences for theselection of the RAT type on which the UE can communicate and receivethe desired service, being the football game in this case.

According to some embodiments, the step of selecting a RAT typedifferent from the current RAT type, which is the RAT type on which theUE communicates at the moment, respecting the priorities andpreferences, corresponds to the step 220 of FIG. 2, determining anupdated RAT type, which is an implication of having an affirmativeanswer to the interrogation in step 216, whether to update the currentRAT type to one of the allowed RAT type.

Having performed the step of selecting a RAT type different from thecurrent, the subsequent step is the step of providing an updated RATtype request to the UE, step 622. This step may be performed bycommunicating RAT type information over a novel interface between thePCRF and the UE.

In FIG. 2, this step corresponds to the step 222, sending updated RATtype request from the PCRF to the UE.

According to an alternative embodiment, updating of the RAT type may behandled by the network of the UE directly, without the need of sendingthe request to the UE in step 622.

It may further be noted that it is the UE source and port IP addressthat are used by the PCRF to match the service request from the AF withthe current IP session in the PCRF, according to some embodiments.

Further AF Steps and Features—Football Game Scenario

After having determined in step 608 that the current RAT type is notamong the allowed RAT types, the step of sending an accept responseS-412 from the PCRF to the AF, according to step 610 in FIG. 6 isperformed, as was described above.

This response is thus received by the AF 300 by receiving the attributerelated message response S-314, as illustrated by step 516, receivingaccept from the PCRF over the reference point Rx, in FIG. 5 illustratingan embodiment of the method of the AF.

In FIG. 2 this step of receiving the accept response corresponds to thestep of sending accept by the PCRF 24 to the AF 26, in the form of anattribute related message response that may be realised by anAA-response, step 214, preceded by determining a match by the comparingunit 406 under control of the control unit 408.

This attribute related message response may contain information to theAF about which RAT type the requested service, in this case the footballgame, can be delivered on and received by the UE.

Alternatively, in case the PCRF in step 612, as illustrated in FIG. 6determines not to trigger one RAT type that is different from thecurrent RAT type, the following step is sending an attribute relatedmessage response S-412 as a reject response from the PCRF to the AF, instep 614, as was described above.

In this case the attribute related message response S-314 as the rejectresponse is therefore received by the AF300, which is illustrated bystep 518 in FIG. 5, receiving reject from the PCRF over the referencepoint Rx.

Again, FIG. 2 also illustrates a step corresponding to step 518, whichis the step of 218 sending reject response in the form of an attributerelated message response that may be realised as a AA-response from thePCRF 24 to the AF 26.

This reject response may thus comprise information to the AF about thatthe requested service of the service request made by the UE, can not beaccepted. The user of the UE can accordingly not experience the footballgame by using the UE, according to this example possibility.

Non 3GPP PCC Architectures

Some embodiments of the invention are mainly described in the context ofthe 3rd Generation Partnership Project (3GPP) PCC architecture. Itshould be kept in mind that the general inventive concept is alsoapplicable to other policy control architectures such as Telecoms &Internet converged Services & Protocols for Advanced Networks (TISPAN),Worldwide Interoperability for Microwave Access (WiMAX), DigitalSubscriber Line (DSL), and others.

This implicates that the extensions to the application node—policy nodeinterface can differ between different standards, for example Diameterin the case of 3GPP, and Service Oriented Architecture Protocol (SOAP)in some other cases, to mention a few examples only.

According to some embodiments, the order of the steps of the methods maybe modified and some steps as illustrated in FIGS. 5 and/or 6 can evenbe deleted without deferring from the scope of protection of saidembodiments.

It is emphasized that the present embodiments can be varied in manyways, of which the alternative embodiments as presented are just a fewexamples. These different embodiments are hence non-limiting examples.The scope of the present invention, however, is only limited by thesubsequently following claims.

It is thus easy to understand that the embodiments comes with a numberof advantages of which one is making possible to specify allowedaccesses for a specific service in run-time during session setup. Onepositive implication of this is that that there is no need to provisionupdated static rules in the policy control unit, such as the PCRF, whena new service is deployed.

Another advantage is that a generic mechanism is provided which allapplications can make use of.

It is also beneficial that it is possible to specify the prioritybetween different access technology types.

It is easier to realize the expected Quality of Experience (QoE) for theend user and to the service provider.

Another advantageous feature is that some embodiments enable a mechanismto update the radio access technology type on which the UE communicatesat the moment.

The invention claimed is:
 1. A method, implemented by a policy node, forprocessing media requests in a wireless communication network,comprising: receiving, from an application node, a list of one or moresupported Radio Access Technology (RAT) types over which a requestedpiece of media is available; determining if the one or more supportedRAT types over which the requested piece of media is available match aRAT type that a requesting wireless terminal is using or is able to use;when the determining indicates that the wireless terminal is using oneof the supported RAT types, transmitting an acceptance response to theapplication node; when the determining indicates that the wirelessterminal is not using and is not able to use any of the supported RATtypes, transmitting a denial response to the application node; and whenthe determining indicates that the wireless terminal is not using, butis able to use, one of the supported RAT types, transmitting, to thewireless terminal, a request for the wireless terminal to start the onesupported RAT type.
 2. The method of claim 1: wherein the acceptanceresponse includes the RAT type being used by the wireless terminal;wherein the acceptance response is transmitted to initiate provision ofthe requested piece of media to the wireless terminal.
 3. The method ofclaim 1 wherein the received list of one or more supported RAT typesserves as an indication that the requesting wireless terminal hasrequested to stream the particular piece of media from the applicationserver.
 4. The method of claim 1 wherein the policy node communicateswith the application node over an Rx interface.
 5. The method of claim 1wherein the policy node comprises a Policy and Charging Rules Function(PCRF).
 6. A policy node operative to process media requests in awireless communication network, comprising circuitry configured as: atransceiving unit configured to receive, from an application node, alist of one or more supported Radio Access Technology (RAT) types overwhich a requested piece of media is available; a comparing unitconfigured to determine if the one or more supported RAT types overwhich the requested piece of media is available match a RAT type that arequesting wireless terminal is using or is able to use; and a controlunit configured to, based on the comparing unit determination: transmit,to the application node, an acceptance response when the wirelessterminal is using one of the supported RAT types; transmit, to theapplication node, a denial response when the wireless terminal is notusing and is not able to use any of the supported RAT types; andtransmit, to the wireless terminal, a request for the wireless terminalto start using one of the supported RAT types when the wireless terminalis not using but is able to use the one of the supported RAT types. 7.The policy node of claim 6: wherein the acceptance response includes theRAT type being used by the wireless terminal; wherein the control unitis configured to initiate provision of the requested piece of media tothe wireless terminal by transmitting the acceptance response.
 8. Thepolicy node of claim 6 wherein the received list of one or moresupported RAT types serves as an indication that the requesting wirelessterminal has requested to stream the particular piece of media from theapplication server.
 9. The policy node of claim 6 wherein thetransceiving unit is configured to communicate with the application nodeover an Rx interface.
 10. The policy node of claim 6 wherein thecomparing unit and control unit serve as a Policy and Charging RulesFunction (PCRF).